<h3>Chapter 2 - Driver/Mudlib Interaction</h3>

<hr size="1">
<a name="2.1"><p><strong>2.1 Driver Review</strong></p></a>
<p>
In <i>LPC Basics</i>, you learned about the functions create(), reset(),
and init(). Of course, today the actual names of these functions may vary from
driver to driver (LPMud 3.2.1 and DGD have no preset name for any of these, and
the Nightmare Object Library sets reset times to a huge time such that the driver
never calls it), but you still have the concept of a constructor function, a periodic
resetting function, and an an inital contact function. Traditionally these functions
were handled as driver applies.
</p>
<p>
<i>Intermediate LPC</i> introduced the main driver loop. This driver loop
basically looks for new connections passing them to the login object, sends
outgoing messages to connected users with messages waiting, processes commands
for connected users with commands pending, calling heart beats, then pending
call outs. DGD has no heart beats, and thus skips the heart beat section.
</p>
<p>
The trend these days is to move away from the init()/add_action() paradigm
and do command handling almost entirely at the mudlib level. In Chapter 5, I
discuss advanced command processing. No matter how you do it, however, you cannot
escape the fact that the driver determines when a command is available and calls
some mudlib level function to process that command.
</p>
<p>
In this chapter, you should get a full understanding of how drivers work
with mudlibs in general.  Naturally, each driver has its own peculiarities.
In the last year, the exact manner in which the driver interacts with the
mudlib has started to become the greatest point of divergence of the LPMud
drivers.  To come to a full understanding of how your driver works, you
should of course read every bit of documentation for your driver.  And
perhaps even read the source code.
</p>

<hr size="1">
<a name="2.2"><p><strong>2.2 Basic Objects</strong></p></a>
<p>
Each driver requires at least one special interface object, and most require
a second object for defining special functions.  With DGD, the primary
interface between the driver and mudlib is the driver object.  Other
drivers use an object called the master object.  In spite of the name
difference, both objects have the same basic purpose, to allow the driver
interact in a few selective cases where it needs to with the mudlib.
</p>
<p>
The difference between DGD and the other drivers becomes more pronounced
with the other basic mudlib object, the auto object for DGD and the simul
efun object for others.  To the end area builder, an auto object acts
just like a simul efun object does, with some minor exceptions.  Namely,
both objects are used to define special functions considered local to all
objects as well as override efuns/kfuns.
</p>
<p>
The differences are certainly much more in depth than I noted above.  Most
of the differences, however, are only truly of interest to people dealing
with the internals of driver design.  Those differences which are relevant
to mudlib design will be discussed in the section on each pair of objects
below.
</p>

<hr size="1">
<a name="2.3"><p><strong>2.3 The master and driver objects</strong></p></a>
<p>
The primary interface between the driver and the mudlib is the master object,
or the driver object on DGD muds.  Though certainly not identical, they serve
the same purpose for the drivers in which they are used, namely to server
as the focus for encapsulating queries the driver makes of the mudlib.  DGD
attempts to limit this severely, and thus the actual make up of the DGD
driver object is quite different from that of the master object for other
drivers.
</p>
<p>
The primary task common to both the master object and driver object is
to identify to which object an incominng connection should be attached.
</p>
